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(54) Multicast and unicast scheduling for a network device 



(57) A method and apparatus are provided for 
scheduling unicast and multicast data in an input- 
queued network device. According to one aspect of the 
present invention, a combined schedule is created by 
pipelined staging of multicast and unicast scheduling. 

Multicast cells are scheduled for transmission 
among multiple interfaces of a crossbar by performing a 
multicast cell scheduling cycle for multiple classes of 



service that are supported by the network device. Then, 
unicast cells are scheduled for transmission among the 
interfaces at a lower priority than the previously sched- 
uled multicast cells by performing a unicast cell sched- 
uling cycle for the multiple classes of service using only 
those interfaces that remain unmatched after comple- 
tion of the multicast cell scheduling cycle. 
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Description 



Field of the Invention 



[0001] The invention relates generally to the field of 
computer networking devices. More particularly, the 
invention relates to a method and apparatus for provid- 
ing efficient unicast and multicast scheduling and high 
throughput for both unicast and multicast traffic. The 
method and apparatus may be embodied in a network 
device, such as a router or switch that employs input 
buffering and a switched backplane architecture. 

Description of the Related Art 

[0002] The current trend in high performance rout- 
ers is away from shared backplanes that allow only a 
single bus transaction at a time (e.g., the transfer of one 
packet across the bus) and toward much faster switched 
backplanes that support multiple bus transactions at 
once (e.g., the forwarding of packets across the back- 
plane by multiple ports simultaneously). For conven- 
ience, typically, packets are transferred across the 
switched backplane in fixed size "cells." In this manner, 
the scheduling of the backplane's input and output ports 
may be synchronized in fixed size increments of time 
referred to herein as "time slots," "cell scheduling 
cycles," or "cell cycles." A scheduling algorithm is 
employed to determine a "configuration" of the back- 
plane for a particular time slot by identifying non-con- 
flicting pairs of inputs and outputs which may be 
connected during the time slot. Because efficient 
scheduling of the backplane is important to the perform- 
ance of the system as a whole, much time and effort has 
been spent developing and evaluating various schedul- 
ing approaches, 

[0003] The recently developed ESLIP algorithm is 
an example of one of the more advanced scheduling 
approaches. The ESLIP algorithm is an enhanced ver- 
sion of iSLIP. an iterative unicast scheduling algorithm. 
Recognizing the importance of efficiently supporting 
multicast traffic, ESLIP combines unicast and multicast 
scheduling. The implementation of the ESLIP algorithm 
involves scheduling both unicast and multicast traffic 
simultaneously in a single scheduler. Consequently, to 
support multiple classes of service, the ESLIP sched- 
uler needs to choose between competing unicast and 
multicast cells having the same priority. The ESLIP 
algorithm resolves contention between unicast and mul- 
ticast cells of the same priority by alternating its prefer- 
ence between multicast and unicast each cell cycle. In 
this manner, both multicast and unicast traffic may be 
transferred across the backplane each cell cycle. During 
one cell cycle, unicast queues representing a particular 
priority are chosen to source a cell before multicast 
queues representing the same priority; and in the sub- 
sequent cell cycle, multicast cells are favored over uni- 
cast cells of equal priority. A more detailed description 



of ESLIP can be found in N. McKeown, "Fast Switched 
Backplane for a Gigabit Switched Router," Cisco Sys- 
tems white paper. Nov. 1997. 

[0004] While the ESLIP algorithm is admirable in 
5 terms of its performance, it has some limitations in 
terms of flexibility, predictability of scheduling delay, and 
variability of packet delay. With regard to flexibility, nota- 
bly, there is no mechanism by which the frequency of 
multicast servicing can be varied. The fixed alternating 
10 priority scheme suggested by the ESLIP algorithm 
schedules both multicast and unicast traffic every time 
slot. With regard to delay, it is desirable to have guaran- 
teed deterministic and bounded delay for a high priority 
multicast cell at the head of its queue. Additionally, it is 
15 advantageous to minimize the variability of packet delay. 
For example, output link scheduling can be made more 
efficient if low packet delay variability across the back- 
plane can be achieved. 

[0005] In addition, prior art schedulers have various 
20 other disadvantages that are overcome by aspects of 
the present invention, as described in the detailed 
description which follows. 
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Brief Summary Of The Invention 



[0006] A method and apparatus for scheduling uni- 
cast and multicast data in an input-queued network 
device are described. According to one aspect of the 
present invention, a combined schedule is created by 
30 pipelined staging of multicast and unicast scheduling. 
[0007] Multicast cells are scheduled for transmis- 
sion among multiple interfaces of a crossbar by per- 
forming a multicast cell scheduling cycle for multiple 
classes of service that are supported by the network 
35 device. Then, unicast cells are scheduled for transmis- 
sion among the interfaces at a lower priority than the 
previously scheduled multicast cells by performing a 
unicast celt scheduling cycle for the multiple classes of 
service using only those interfaces that remain 
40 unmatched after completion of the multicast cell sched- 
uling cycle. 

[0008] Other features of the present invention will 
be apparent from the accompanying drawings and from 
the detailed description which follows. 

45 

Brief Description Of The Several Views Of The Draw- 
ings 

[0009] The present invention is illustrated byway of 
so example, and not by way of limitation, in the figures of 
the accompanying drawings and in which like reference 
numerals refer to similar elements and in which: 

Figure 1 is a simplified block diagram of a network 
55 device according to one embodiment of the present 
invention. 

Figure 2 is a high level block diagram of various 
functional units that may be employed in a fabric 
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configuration manager according to one embodi- 
ment of the present invention. 
Figure 3 is a flow diagram illustrating multicast 
scheduling processing according to one embodi- 
ment of the present invention. 5 
Figure 4 conceptually illustrates a multicast sched- 
uling cycle according to one embodiment of the 
present invention. 

Figure 5 is a high level block diagram of a hardware 
implementation of a multicast scheduler according w 
to one embodiment of the present invention. 
Figure 6 is a flow diagram illustrating unicast sched- 
uling processing according to one embodiment of 
the present invention. 

Figures 7A and 7B conceptually illustrate a unicast 15 
scheduling cycle according to one. embodiment of 
the present invention. 

Figure 8 is a high level block diagram of a hardware 
implementation of a unicast scheduler according to 
one embodiment of the present invention. 20 
Figures 9A and 9B depict exemplary round-robin 
arbiters that may be used in accordance with one 
embodiment of the present invention. 
Figure 1 0A is a flow diagram illustrating combined 
scheduling processing for two types of traffic 25 
according to one embodiment of the present inven- 
tion. 

Figure 1 0B is a flow diagram illustrating combined 
unicast and multicast scheduling processing 
according to one embodiment of the present inven- 30 
tion. 

Figure 10C is a flow diagram illustrating combined 
unicast and multicast scheduling processing 
according to another embodiment of the present 
invention. 35 
Figure 11A conceptually illustrates a pipelined 
approach for scheduling multicast and unicast traf- 
fic according to one embodiment of the present 
invention. 

Figure 11B conceptually illustrates a pipelined 40 
approach for scheduling multicast and unicast traf- 
fic according to one embodiment of the present 
invention. 

Figure 12 is a flow diagram illustrating backpres- 
sure processing according to one embodiment of 45 
the present invention. 

Figure 13 is a block diagram of a hardware imple- 
mentation of a portion of the backpressure logic 
according to one embodiment of the present inven- 
tion, so 

Detailed Description Of The Invention 

[0010] A method and apparatus are described for 
scheduling unicast and multicast traffic in an input- 55 
queued network device. In the following description, for 
the purposes of explanation, numerous specific details 
are set forth in order to provide a thorough understand- 



ing of the present invention. It will be apparent, however, 
to one skilled in the art that the present invention may 
be practiced without some of these specific details. In 
other instances, well-known structures and devices are 
shown in block diagram form. 

[0011] The present invention includes various 
steps, which will be described below. The steps of the 
present invention may be performed by hardware com- 
ponents or may be embodied in machine-executable 
instructions, which may be used to cause a general-pur- 
pose or special-purpose processor or logic circuits pro- 
grammed with the instructions to perform the steps. 
Alternatively, the steps may be performed by a combi- 
nation of hardware and software. 

[0012] Assuming sufficient processing speed can 
be made available to accommodate cell scheduling time 
constraints, it is envisioned that the present invention 
may also be provided as a computer program product 
which may include a machine-readable medium having 
stored thereon instructions which may be used to pro- 
gram a computer (or other electronic devices) to per- 
form a process according to the present invention. The 
machine-readable medium may include, but is not lim- 
ited to, floppy diskettes, optical disks, CD-ROMs, and 
magneto-optical disks, ROMs, RAMs, EPROMs. EEP- 
ROMs, flash memory, magnet or optical cards, or other 
type of media / machine-readable medium suitable for 
storing electronic instructions. Moreover, the present 
invention may also be downloaded as a computer pro- 
gram product, wherein the program may be transferred 
from a remote computer (e.g., a server) to a requesting 
computer (e.g., a client) by way of data signals embod- 
ied in a carrier wave or other propagation medium via a 
communication link (e.g., a modem or network connec- 
tion). 

[0013] Importantly, while embodiments of the 
present invention will be described with respect to a net- 
work device, such as a router, or a Layer 2 or Layer 3 
switch operable within a TCP/IP network, the method 
and apparatus described herein are equally applicable 
to Asynchronous Transfer Mode (ATM) networks and 
networking devices, and other devices such as multi- 
processing computers, for example. Additionally, while 
various embodiments of the present invention are 
described in connection with a networking device that 
recognizes four different classes of service, the method 
and apparatus described herein are not limited to such 
a configuration. 

EXEMPLARY NETWORK DEVICE ARCHITECTURE 

[0014] A simplified block diagram illustrating an 
exemplary network device 100 employing a switched 
backplane architecture will briefly be described with ref- 
erence to Figure 1. According to the embodiment 
depicted, the network device 100 includes a plurality of 
line cards 105, a fabric 120, and a fabric configuration 
manager 110 (also referred to as the fabric arbiter). 
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Each of the line cards 105 is coupled to a corresponding 
fabric interface 11 5 of the fabric 120. The line cards 105 
each include forwarding logic 106, a fabric input 107 
(also referred to as an input port), output scheduling 
logic 108, and a fabric output 109 (also referred to as an $ 
output port). According to one embodiment, the for- 
warding logic 106 determines the output port(s) to 
which received packets need to be forwarded and per- 
forms other Internet Protocol (IP) header processing, 
such as appending the next hop Media Access Control w 
(MAC) address retrieved from a forwarding database 
(not shown), updating the time-to-live (TTL) field, and 
calculating a new header checksum. 
[0015] According to one embodiment, in order to 
simplify processing throughout the network device 100, is 
packets are segmented into fixed length cells before 
being queued for transfer across the fabric 120 at the 
fabric input 107. The fabric input 107 may include a set 
of virtual output queues (VOQs) (not shown) for each 
class of service supported. By providing a dedicated 20 
queue per fabric input 107 per class of service, the 
head-of-line blocking phenomenon experienced in sim- 
ple input buffered networking devices that employ a sin- 
gle first-in-first-out (FIFO) queue is eliminated. The 
fabric input 107 may also include a dedicated multicast 25 
queue (not shown) for multicast traffic for each class of 
service. 

[0016] The fabric 120 allows multiple line cards 105 
to communicate with each other simultaneously. 
According to one embodiment, the fabric 120 comprises 30 
a crossbar switch. Advantageously, since all crossbars 
are internally non-blocking, every input and output port 
is capable of transferring data simultaneously during 
each time slot. A crossbar implementation is addition- 
ally advantageous due to its simplicity and its ability to 35 
deliver multicast data to multiple outputs simultaneously 
by replicating cells within its interconnected fabric, 
[0017] The novel fabric configuration manager 110 
is coupled to each line card 105 and the fabric 120. At 
the beginning of each cell scheduling cycle, through its 40 
interface with the line cards 105, the fabric configuration 
manager 110 may receive information regarding the 
cells that are ready for transmission across the fabric 
120, Briefly, the fabric configuration manager 110 is 
responsible for determining a conflict-free matching of 45 
ports each time slot, configuring the fabric 120 to form 
connections between the appropriate fabric interfaces 
115, and communicating the scheduling decisions to 
the fabric inputs 1 07. As will be described further below, 
the novel fabric configuration manager 110 includes so 
independent unicast and multicast schedulers that allow 
flexible scheduling, such as pipelined staging of multi- 
cast and unicast scheduling and programmable multi- 
cast scheduling frequency 

[0018] The output scheduling logic 108 is coupled 55 
to the fabric output 109 to schedule the time at which 
cells are reassembled into packets and transmitted on . 
the output link. In order to meet specific quality of serv- 
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ice (QoS) requirements associated with the classes of 
service supported, the fabric output 109 may include a 
dedicated output queue per class of service. 
[0019] The functional units described above may be 
implemented separately or in various combinations in 
various types of programmable or hardcoded logic, 
such as FPGAs, TTL logic, or an application specific 
integrated circuits (ASICs). Alternatively, the functional 
units described above may be implemented with a proc- 
essor or other components of a programmed computer 
that perform a series of operations dictated by software 
or firmware, or a combination of hardware and software 
or firmware. Importantly, the present invention is not lim- 
ited to a particular implementation of these functional 
units. 

EXEMPLARY FA8RIC CONFIGURATIO N MANAGER 

[0020] The fabric configuration manager 110 
ensures that queue lengths at the input and output ports 
are maintained at reasonable levels and that the 
amount of delay experienced by packets traversing the 
network device is low : The fabric configuration manager 
110 seeks to achieve these goals by providing ample 
service bandwidth to all ports. Responsive to transmis- 
sion requests received from the input ports 107, the fab- 
ric configuration manager 110 provides each of the 
input ports 107 with an equal opportunity to transfer 
cells to desired output ports 109. Additionally, the fabric 
configuration manager 110 employs a novel mechanism 
to combine multicast and unicast scheduling cycles 
which allows variable rate multicast servicing to be 
achieved while supplying both types of traffic with fair 
access to the fabric 120. 

[0021] Referring now to Figure 2, various functional 
units wilt now be described that may be employed in the 
fabric configuration manager 110 according to one 
embodiment of the present invention. In the embodi- 
ment depicted, the fabric configuration manager 110 
includes an input queue status block 205, time slot 
scheduling control logic 210, a multicast scheduler 215, 
and a unicast scheduler 220, 

[0022] The multicast scheduler 215 implements a 
fabric arbitration algorithm for multicast cells. The multi- 
cast scheduler 215 seeks to provide bounded schedul- 
ing delay and low variability by transferring at least one 
high priority multicast cell completely in each multicast 
scheduling cycle. Importantly, this preference also sim- 
plifies the implementation of the multicast scheduler 
215 and takes advantage of the multicast capability of 
the fabric 120, Details regarding the implementation of 
the multicast scheduler 215 and the processing per- 
formed by the multicast scheduler 215 are described 
below. 

[0023] The unicast scheduler 220 implements a 
fabric arbitration algorithm for unicast cells. In one 
embodiment, the unicast scheduler 220 operates in 
accordance with the iSLIP unicast scheduling algorithm 
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which is described below. However, in other embodi- 
ments, a variety of other unicast scheduling approaches 
may be employed such as, Programmable Iterative 
Matching (PIM), iterative Longest Queue First (i-LQF), 
iterative Oldest Cell First (i-OCF) or variants and combi- 
nations thereof. 

[0024] The time slot scheduling control logic 210 
initiates multicast and unicast scheduling during the 
appropriate scheduling time slots. In one embodiment, 
unicast scheduling is performed every time slot while 
multicast scheduling is performed every other time slot. 
In another embodiment, the frequency at which multi- 
cast scheduling is performed is a programmable param- 
eter, e.g., multicast scheduling frequency 245, that may 
be provided by the network administrator, for example. 
Assuming that a time slot is not long enough to allow 
both multicast scheduling and unicast scheduling to be 
completed if performed sequentially, according to one 
embodiment, the scheduling of multicast and unicast 
cells that are to be delivered during the same time slot 
may be staged in a pipelined fashion. For example, mul- 
ticast scheduling may be performed in advance of the 
time slot in which the results are used. In this manner, 
during time slots in which only unicast cells are trans- 
ferred across the fabric 120, both multicast and unicast 
scheduling may be performed independently and in par- 
allel. During time slots in which both multicast and uni- 
cast cells are to be transferred, the results of the 
multicast scheduling cycle that were performed in 
advance are fed into the unicast scheduler 220 and the 
unicast scheduler 220 then schedules unicast cells 
whose ports are not being used by the previously 
scheduled multicast cells. Importantly while specific 
multicast and unicast scheduling approaches are 
described herein, the mechanism for producing a com- 
bined schedule is not limited to these particular 
approaches. The novel separation and pipelined stag- 
ing of multicast and unicast scheduling and the parallel 
operation of the multicast and unicast scheduling that 
will be described further below are equally applicable to 
other current and future scheduling approaches. 
[0025] In the embodiment depicted, the fabric con- 
figuration manager 110 has control information inter- 
faces with the input ports 107. the output ports 109. and 
the fabric 120. 

[0026] ' Control information generated by the fabric 
configuration manager 110 includes information regard- 
ing queue selection 240 and 255 which is sent each 
time slot to those of the input ports and output ports par- 
ticipating in the schedule generated by the multicast 
scheduler 215 and/or the unicast scheduler 220. Addi- 
tionally, each time slot, the fabric configuration manager 
110 produces a fabric configuration 260 based upon the 
. current schedule. The fabric configuration 260 is com- 
municated to the fabric 1 20 each time slot to activate the 
fabric 120 and cause the fabric 120 to form appropriate 
connections among the fabric interfaces 115 to accom- 
modate the current schedule. 



[0027] In this example, control information received 
by the fabric configuration manager 110 from the input 
ports 107 includes input queue state information 230 
and transmit requests 235. According to one embodi- 
5 ment, input queue state information 230 comprises 
information on newly received cells such as an indica- 
tion of the queue with which the cell is associated (iden- 
tified by the port and the class of service, for example) 
and the output port(s) to which the cell is destined. In 
10 this manner, the current state of the queues at each of 
the input ports may be maintained in the input queue 
status block 205. In alternative embodiments, queue 
status may be kept at the input ports 107. 
[0028] Transmit requests 235 may be received from 
15 the input ports 107 at the beginning of each time slot. 
The transmit requests 235 identify the output port(s), if 
any, to which the corresponding input port has a cell 
ready to be transferred. As will be described further 
below, the transmit requests 235 may be presented to 
20 one or both of the multicast scheduler 215 and the uni- 
cast scheduler 220 in the form of request vectors for 
each output port 109. Each request vector identifies 
those of the input ports 107 with requests for a particu- 
lar output port 109. 
25 [0029] The fabric configuration manager 110 also 
receives control information from the output ports 109. 
For example, a back pressure signal 250 may identify 
output ports 109 having one or more output queues that 
have exceeded a predetermined threshold of pending 
30 cells. Briefly, in network devices employing "speedup," 
e.g.. those operating their fabrics faster than the input 
and output port capacity, a back pressure signaling 
mechanism is important to protect the output ports from 
excess traffic from the fabric. In prior architectures, a 
35 back pressure signal is typically coupled directly from 
each of the output ports 109 to each of the input ports 
107. Typically, output ports assert their back pressure 
signal upon exceeding a predetermined threshold of 
pending cells. Subsequently, when the number of pend- 
40 ing cells falls below another predetermined threshold, 
the output port deasserts the back pressure signal. 
While an output port is back pressuring, input ports do 
not transfer cells to that output port. When VOQs are 
employed at the input ports 107, back pressure does 
45 not cause difficulties for unicast traffic since a head-of- 
line unicast cell destined for a back pressuring output 
only blocks other cells destined for the same output. 
However, a complication occurs for multicast traffic. 
When a particular output port is back pressuring, a 
50 head-of-line multicast cell blocks the rest of the cells in 
the multicast queue, which may or may not be destined 
for the back pressuring port. The novel back pressure 
mechanism described below provides for centralized 
back pressure handling and solves this head-of-line 
55 blocking problem for multicast traffic. 
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Multicast Scheduling 

[0030] Having described the environment in which 
the various features of the present invention may imple- 
mented, multicast scheduling cycle processing will now 5 
be described with reference to the flow diagram of Fig- 
ure 3. Briefly, in the embodiment illustrated, the multi- 
cast scheduling cycle processing is broken down into 
four phases: a request phase, a grant phase, an accept 
phase, and an update phase. The four phases are 10 
repeated sequentially for each class of service in 
decreasing order of priority each multicast scheduling 
C y C | e< Advantageously, according to one feature of the 
present embodiment, only a single scheduling iteration 
is performed per class of service, thereby reducing the is 
time required for multicast scheduling over prior multi- 
cast scheduling approaches. 

[0031] At the beginning of each scheduling cycle, 
all input ports and output ports are initially unmatched. 
Only those that remain unmatched at the end of an iter- 20 
ation are available for matching in the next iteration. The 
scheduling cycle begins at step 310 by performing the 
request phase. During the request phase, each of the 
input ports 107 communicates a transmit request 235, 
in the form of a bit vector, for example, to the fabric con- 25 
figuration manager 110. Based upon the transmit 
requests 235. request vectors are formed for each out- 
put port 109. Recall, each request vector identifies 
those of the input ports 107 with requests for a particu- 
lar output port 109. For purposes of illustration, the 30 
transformation of transmit requests 235 to request vec- 
tors may be thought of conceptually as accumulating 
transmit requests 235 as columns of a table and subse- 
quently reading rows of the accumulated information to 
determine the corresponding request vectors. 35 
[0032] At step 320, the grant phase is performed. 
During the grant phase, the multicast scheduler 215 
evaluates the request vectors for the current class of 
service corresponding to those of the output ports that 
• remain available for matching. The purpose of this evai- 40 
uation is to determine a conflict-free matching of input 
ports 107 and output ports 109. According to one 
embodiment, in order to ensure that each of the input 
ports 107 is provided with fair access to the output ports 
109, a single global indicator that identifies which of the 45 
input ports is to receive priority for the current schedul- 
ing cycle is maintained for each class of service. In one 
embodiment, this priority indicator comprises a modulo 
N counter, referred to as the global multicast round 
robin counter (GRRC), where N represents the number so 
of ports. In this example, evaluating request vectors 
involves searching the request vector in a circular fash- 
ion starting from the input port 107 identified by the 
GRRC for the appropriate class of service. The first 
input port 107 in the request vector that has a request ss 
for the output port 109. and is available for matching is 
selected to receive access to the output port 109. 
Finally, after the request vectors for the current class of 



service have been evaluated, those of the output ports 
109 that were matched during the current iteration 
should be marked as unavailable. In this manner, the 
matched output ports 109 are removed from further 
consideration in subsequent iterations of the scheduling 
cycle. 

[0033] At step 330, the accept phase is performed. 
Since multicast cells may be destined for more than one 
output port 1 09, input ports 1 07 may receive grants from 
multiple output ports 109. During the accept phase, 
regardless of the number received, each input port 107 
accepts all grants. This manner of acceptance 
expresses the multicast algorithm's preference for com- 
pletely transferring at least one high priority multicast 
cell across the fabric 120 during each multicast sched- 
uling cycle. Additionally, by accepting all grants, the mul- 
ticast capability of the fabric 120 is utilized to perform 
cell replication. Finally, those of the input ports 107 that 
were matched during the current iteration should be 
marked as unavailable. In this manner, the matched 
input ports 107 are removed from further consideration 
in subsequent iterations of the scheduling cycle. 
[0034] At step 340, the update phase is performed. 
During the update phase, the priority indicator, e.g., the 
GRRC, for the current class of service is incremented to 
point to the next input port that has a non-fully-granted 
request if any of the following criterion are met: 
[0035] The cell at the head of the multicast queue 
associated with the input port identified by the priority 
indicator has been sent to all output ports to which it is 
destined, 

No cells are pending on the multicast queue, or 
one or more of the output ports to which the cell is 
destined was unavailable for matching during the 
scheduling cycle due to back pressure. 

[0036] Importantly, the priority indicator for the high- 
est priority class of service will always be incremented, 
since one of the above criteria will always be true for this 
class of service. Additionally, it should be noted that as 
a result of the processing described above, "fanout- 
splitting" is supported . If any of the output ports 1 09 that 
has a request from the input port 107 pointed to by the 
priority indicator is unavailable, the cell is partially deliv- 
ered to those of the output ports 109 that are available. 
Therefore, a cell may be transferred to the output ports 
109 to which it is destined over a number of scheduling 
cycles. 

[0037] The update phase may also include updat- 
ing the request vectors for use in the next iteration. In 
one embodiment, the request vectors may be modified 
based upon the accepts such thabno requests will be 
presented in subsequent iterations from an input port 
that has accepted an output port and/or such that no 
requests will be presented to an output port that has 
been accepted by an input port. 

[0038] At step 350, it is determined if the last class 
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of service has been scheduled. If not, processing con- 
tinues with step 31 0 for the next class of service. Other- 
wise, if the last class of service has been scheduled, 
then the multicast scheduling cycle is complete. 
[0039] Referring now to Figure 4, one iteration of an 
exemplary multicast scheduling cycle will be described. 
Communication of transmit request information is 
depicted as a solid line from an input port to an output 
port and grants are depicted as dotted lines from output 
ports to input ports. According to this example, there are 
four input ports numbered 0 to 3 and four output ports 
numbered 0 to 3. The input ports each have a corre- 
sponding unavailability indicator 405-408. Similarly, 
each output port has a corresponding unavailability indi- 
cator 415-418. In this example, the global priority indica- 
tor comprises a GRRC 450 which currently points to 
input port 1. Therefore, input port 1 will receive priority 
over the other input ports during this scheduling cycle. 
[0040] In this example, input port 0 has a multicast 
cell ready for delivery to output ports 1 and 2, the head- 
of-line multicast cell at input port 1 is destined for output 
ports 0, 1 and 3, no multicast cells are pending at input 
port 2, and input port 3 has a multicast cell that is ready 
to be transferred to output port 2. While, in reality, this 
control information is communicated from the input 
ports 107 to the fabric configuration manager 110, for 
purposes of this example, the communication is con- 
ceptually represented as being communicated between 
input ports 0-3 and output ports 0-3. At any rate, during 
the request phase (step 310) the input ports each com- 
municate their transmit request information to the output 
ports. 

[0041] The transmit request information accumu- 
lated at output port 0 forms request vector 425. Simi- 
larly, request vectors 426-428 are formed at output 
ports 1-3, respectively. The request vectors 425-428 
have a bit position corresponding to each of the input 
ports 0-3. A bit is set in the request vectors 435-428 
when the corresponding input port has a multicast cell 
ready for delivery to the output port. The bit remains 
clear if the corresponding input port has no cell destined 
for the output port. 

[0042] During the grant phase (step 320), each out- 
put port that is available searches its corresponding 
request vector 425-428, respectively, in a circular fash- 
ion beginning with the input port identified by GRRC 
450 to select the first available input port 0-3 that has a 
request for that output port. In this example, the first 
available input port that has a request for output port 0 
is input port 1 . Input port 1 is also the first available input 
port that has a request for output port 1 . Output port 2 
selects input port 3 and output port 3 selects input port 
1. After the output ports have selected an input port, 
grants are issued to those of the input ports that have 
been selected and those of the output ports that gave a 
grant to an input port set their corresponding unavaila- 
bility indicators. In this example, therefore, all of the out- 
put ports would set their output unavailability indicators 



415-418. 

[0043] During the accept phase (step 330), each 
input port accepts all grants received and each input 
port that received at least one grant sets its input una- 
5 vaitability indicator 405-408. In this example, input ports 
1 and 3 would set their corresponding unavailability indi- 
cators. Therefore, input ports 1 and 3 would not partici- 
pate in subsequent iterations until a new scheduling 
cycle begins. 

10 [0044] During the update phase (step 340), the 
GRRC update criteria are evaluated and the GRRC 450 
is incremented to point to input port 2. Therefore, in the 
next scheduling cycle, input port 2 will receive priority 
over input ports 0, 1 and 3. 

15 [0045] Assuming the fabric 120 were configured 
according to this scheduling cycle iteration, the multi- 
cast cell from input port 3 would be delivered to output 
port 2 and the multicast cell from input port 1 would be 
delivered to output ports 0, 1 and 3. 

20 [0046] Figure 5 is a high level block diagram of a 
hardware implementation of a multicast scheduler 
according to one embodiment of the present invention. 
According to this embodiment, the multicast scheduler 
500 consists of a set of priority request vector registers 

25 for each class of service 510-513, a multiplexer (MUX) 
520, iteration control logic 530, a set of active request 
vector registers 540, a set of output grant arbiters 550, 
a set of priority indicators, e.g., GRRCs 580-583, a MUX 
560, and a set of grant vector registers 570. 

30 [0047] During a multicast scheduling cycle, iteration 
control logic 530 causes an arbitration iteration to be 
performed for each class of service. The priority request 
vector registers 510-513 are coupled to the input of 
MUX 520. Iteration control logic 530 is coupled to MUX 

35 520 to select the set of priority request vectors for the 
current iteration. The output of MUX 520 is coupled to 
the set of active request vector registers 540. As a 
result, the priority request vectors selected for the cur- 
rent iteration are passed to the active request vector 

40 registers 540. Iteration control logic 530 is also coupled 
to MUX 560 to select the GRRC appropriate for the cur- 
rent iteration. The GRRCs 580-583 are coupled to the 
input of MUX 560 and the output of MUX 560 is coupled 
to each of the output grant arbiters 55, thereby program- 

45 ming each output grant arbiter 550 with the selected 
GRRC. 

[0048] The active request vector registers 540 are 
coupled to the output grant arbiters 550. Each of the 
output grant arbiters 550 are presented with priorities 

so and a request vector from the active request vector reg- 
isters 540. For example, output grant arbiter 0 receives 
request vector 541 which indicates which of the input 
ports have a request for output port 0 and identifies the 
priorities associated with each of the requests. Similarly, 

55 output grant arbiters 1 and N receive request vectors 
542 and 543, respectively and the associated priorities. 
[0049] Each output grant arbiter 550 looks at the 
inputs associated with the class of service selected for 
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the current iteration and selects one request on behalf 
of the corresponding output port. According to one 
embodiment, the output grant arbiters 550 select the 
request closest in priority to the GRRC in a circular fash- 
ion. A vector identifying the selected and non-selected 
input ports is then stored in the grant vector registers 
570. Once an output grant arbiter 550 has matched an 
input port to its corresponding output port, it is disabled 
in all further iterations of the multicast scheduling cycle 
in order to prevent the output grant arbiter 550 from 
making additional matches. 

Unicast Scheduling 

[0050] Having described an exemplary hardware 
implementation of a multicast scheduler and exemplary 
multicast scheduling processing, unicast scheduling 
cycle processing will now be described with reference to 
the flow diagram of Figure 6. 

[0051] Briefly in the embodiment illustrated, in a 
manner similar to multicast scheduling cycle process- 
ing, the unicast scheduling cycle processing is concep- 
tually divided into four phases: a request phase, a grant 
phase, an accept phase, and an update phase. The four 
phases may be repeated for multiple iterations until no 
further port matchings can be established or until the 
time allocated to unicast scheduling has expired. Each 
iteration seeks to identify one or more port matchings 
that were not made in earlier iterations. The unicast 
algorithm is similar to the multicast algorithm, but it is 
more complicated due to the fact that there can be con- 
tention among two or more queues on the input side. 
For example, as with multicast, an input may receive 
grants from multiple outputs. However, in the unicast 
case, an input can be paired with only one output and 
can therefore accept only one of the grants received. 
[0052] As above, at the beginning of each schedul- 
ing cycle, all input ports and output ports are initially 
unmatched (an exception will be noted below with 
regard to the novel combination of multicast and unicast 
scheduling). Only those that remain unmatched at the 
end of an iteration are available for matching in the next 
iteration. The unicast scheduling cycle begins at step 
610 by performing the request phase. During the 
request phase, each of the input ports 107 communi- 
cates a transmit request 235 to the fabric configuration 
manager 110 indicating the output ports 109 to which 
cells at the head of its VOQs are destined. Based upon 
the transmit requests 235, request vectors are formed 
for each output port 109 that identify those of the input 
ports 107 with requests for the output port 109, 
[0053] At step 620, the grant phase is performed. 
According to one embodiment, in order to ensure that 
each of the input ports 107 is provided with fair access 
to the output ports 109, a per output port priority indica- 
tor is maintained for each class of service. The priority 
indicator identifies which of the input ports receives top 
priority to the output port for the current scheduling iter- 
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ation. In one embodiment, the priority indicators are 
modulo N counters, referred to as output round robin 
counters (ORRCs), where N represents the number of 
ports. In any event, during the grant phase, the unicast 

5 scheduler 220 evaluates the request vectors for each 
output port in a parallel fashion. If the output port is 
available for matching with an input port, then the 
request vectors for each class of service are evaluated 
to determine to which input port a grant will be made. 

10 The evaluation begins with the input port pointed to by 
the corresponding ORRC and proceeds in a circular 
fashion until an available input port is found that has a 
request for the output port. Impo'rtantly, because each 
class of service is independent, the operations for each 

15 class of service may be performed in parallel. However, 
if two input ports are selected for matching with an out- 
put port, then the input port selected from the request 
vector corresponding to the higher priority class of serv- 
ice receives the grant over the input port selected from 

20 the request vector corresponding to the lower priority 
class of service. At any rate, based upon the results of 
the evaluation of the request vectors, grants are made 
to the selected inputs forming a grant vector for each 
input port indicating the output ports 109 that have 

25 granted a request from the input port 107. 

[0054] At step 630, the accept phase is performed. 
Since two or more VOQs may have.a head of line cell 
pending for different output ports 109, input ports 107 
may receive grants from multiple output ports 109. Dur- 

30 ing the accept phase, the unicast scheduler 220 evalu- 
ates the grant vectors for each input port that is 
available for matching with an output port (in parallel) 
and accepts only one grant per available input port. 
According to one embodiment, a per input port priority 

35 indicator is maintained for each class of service. The 
priority indicator identifies which of the output ports that 
is given top priority by the input port for the current 
scheduling iteration. In one embodiment, the priority 
indicators are modulo N counters, referred to as input 

40 round robin counters (IRRCs), where N represents the 
number of ports. In any event, in order to accomplish the 
evaluation of a grant vector, the unicast scheduler 220 
begins with the output port pointed to by the corre- 
sponding IRRC and proceeds in a circular fashion until 

45 an available output port is found that has issued a grant 
to the input port. As above, because each class of serv- 
ice is independent, the operations for each class of 
service may be performed in parallel. Should more than 
one output port be selected for matching with an input 
50 port, then the output port selected from the grant vector 
corresponding to the higher priority class of service is 
accepted. Based upon the results of the evaluation of 
the grant vectors, accepts are made to the selected out- 
puts. Finally, those of the input ports 107 and output 
55 ports 1 09 that were matched during the current iteration 
(as determined by the accepts) should be marked as 
unavailable. In this manner the matched ports are 
removed from further consideration in subsequent itera- 
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tions of the scheduling cycle. 

[0055] At step 640, the update phase is performed. 
The update phase includes updating the request vec- 
tors for use in the next iteration and updating the priority 
indicators, e.g., the ORRC values and the IRRC values. 
In one embodiment, the request vectors may be modi- 
fied based upon the accepts such that no requests will 
be presented in subsequent iterations from an input port 
that has accepted an output port and/or such that no 
requests will be presented to an output port that has 
been accepted by an input port. With regard to update 
of the priority indicators, an ORRC is incremented if 
either the input port to which it points has been serviced 
by the corresponding output port (e.g., the output port 
has issued a grant to the input port which has been 
accepted for the corresponding class of service) or the 
input port requires no service from the output port (e.g., 
the input port has no unicast cells pending for the corre- 
sponding output port at the corresponding class of serv- 
ice). Similarly, an IRRC is incremented if either the 
output port to which it points has been serviced by the 
corresponding input port (e.g., the input port has 
accepted a grant to the output port for the correspond- 
ing class of service) or the output port requires no serv- 
ice from the input port (e.g., the output port has issued 
no grant to the corresponding input port for the corre- 
sponding class of service). Importantly, the priority indi- 
cators are updated only after the first iteration of a 
scheduling cycle. 

[0056] Before discussing the update mechanism 
further, it may be useful to describe the overall function- 
ing of the ORRCs and the IRRCs. The ORRCs and the 
IRRCs are tools that ensure that the unicast scheduling 
algorithm works in a fair manner and that the delays 
seen by all the input ports are finitely bounded. Each 
scheduling cycle, the ORRC for a particular output port 
steps through the request vector for the output port until 
it encounters a request (e.g., the bit it is pointing to is set 
indicating the corresponding input port has issued a 
request to the output port). The ORRC remains at this 
value until the request is serviced. This behavior 
ensures that the output port will always send a grant to 
this input port at every opportunity. Similarly, the IRRC 
for a particular input port steps through the correspond- 
ing grant vector until it encounters a grant (e.g., the bit it 
is pointing to is set indicating the corresponding output 
port has given a grant to the input port). The IRRC 
remains at this value until this grant is accepted. This 
behavior ensures that the input port will always accept 
the grant from this output port at every opportunity. 
Without such a gating mechanism, there is no guaran- 
tee that a cell will be transmitted. For example, if an 
ORRC was allowed to move ahead of a request without 
servicing it or if an tRRC was allowed to move ahead of 
a grant without servicing it, then the possibility exists 
that the corresponding cell might never be transmitted. 
[0057] Returning to the updating of the ORRC and 
IRRC values, as was mentioned above, they are incre- 



mented only after the first iteration of a scheduling 
cycle. Additionally, the priority indicators may be 
updated differently depending upon the circumstances. 
For example, when a port to which a priority indicator 

5 points does not need service, the priority indicator is 
simply incremented by one (modulo N). However, when 
a port to which a priority indicator points needs service, 
the priority indicator is only updated after that port has 
been serviced; otherwise the priority indicator is not 

10 updated. The ORRC and IRRC values are incremented 
beyond a port that has just been serviced. For each 
IRRC, if the corresponding input port has accepted an 
output port for the corresponding class of service, then 
the IRRC is incremented to point to the output port after 

75 the one accepted. That is, the IRRC is set to one plus 
the value of the output port accepted (modulo N). Simi- 
larly, for each ORRC, if the corresponding output port 
has been accepted by an input port for the correspond- 
ing class of service, then the ORRC is set to one plus 

20 the value of the input port that has accepted the output 
port (modulo N). In this manner, connections made in 
the first iteration are the lowest priority during the next 
scheduling cycle and no connections are starved. 
[0058] At step 650, it is determined if this is the last 

25 iteration of the scheduling cycle. For example, a prede- 
termined number of iterations may be performed or the 
iterations may continue so long as at least one port 
matching was made during the previous iteration. In any 
event, the number of iterations need not exceed the 

30 number of input ports, N, since only one connection can 
be made for each input port. If this is not the last itera- 
tion of the scheduling cycle, processing continues with 
step 610. Otherwise, the unicast scheduling cycle is 
complete and fabric configuration may commence at 

35 step 660. 

[0059] At step 660, fabric configuration is per- 
formed. The fabric 120 is configured one time for each 
unicast scheduling cycle after the current schedule, 
e.g.. the port matchings, has been established. Based 

40 upon the state of the accept signals at the conclusion of 
the unicast scheduling cycle, the unicast scheduler 220 
presents a fabric configuration 260 to the fabric 120. 
The fabric configuration 260 activates the fabric 1 20 and 
directs the fabric 120 to form connections among the 

45 fabric interfaces 1 1 5 that will accommodate the transfer 
of cells across the fabric 120 according to the current 
schedule. 

[0060] Referring to Figures 7A and 7B, one iteration 
of an exemplary unicast scheduling cycle will now be 

so described. Beginning with Figure 7A, communication of 
transmit request information is depicted as a solid line 
from an input port to an output port and grants are 
depicted as dotted lines from output ports to input ports. 
For purposes of this example, four input ports num- 

55 bered 0 to 3 and four output ports numbered 0 to 3 are 
depicted. The input ports each have a corresponding 
unavailability indicator 705-708. Similarly, each output 
port has a corresponding unavailability indicator 715- 
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718. In this example, the output ports each have a cor- 
responding priority indicator, ORRC 0-3, shown pointing 
to input ports 1 , 3, 2, and 0, respectively. Therefore, dur- 
ing this scheduling cycle, input port 1 receives priority 
over any other input ports contending for output port 0, 
input port 3 receives priority over any other input ports 
contending for output port 1 , input port 2 receives prior- 
ity over any other input ports contending for output port 
2, and input port 0 receives priority over any other input 
ports contending for output port 3. 
[0061] In this example, input port 0 has two unicast 
cells ready for transfer across the fabric 120. One is 
destined for output port 1 and the other is destined for 
output port 2. Three head-of-line unicast cells at input 
port 1 are destined for output ports 0, 1 and 3. No uni- 
cast cells are pending at input port 2. Finally, input port 
3 has one unicast cell that is ready to be transferred to 
output port 2. While control information is typically com- 
municated from the input ports 107 to the fabric config- 
uration manager 110, for purposes of this example, the 
communication is conceptually represented as being 
communicated between input ports 0-3 and output ports 
0-3. At any rate, during the request phase (step 610) the 
input ports each communicate their transmit request 
information to the output ports. 

[0062] The transmit request information accumu- 
lated at output port 0 forms request vector 725. Simi- 
larly, request vectors 726-728 are formed at output 
ports 1-3, respectively. The request vectors 725-728 
have a bit position corresponding to each of the input 
ports 0-3. Again, a bit is set in the request vectors 735- 
728 when the corresponding input port has a unicast 
cell ready for delivery to the output port. The bit remains 
clear if the corresponding input port has no unicast cells 
destined for the output port. 

[0063] During the grant phase (step 620), each out- 
put port that is available searches its corresponding 
request vector 725-728, respectively, in a circular fash- 
ion beginning with the input port identified by the asso- 
ciated ORRC 0-3 to select the first available input port 
that has a request for that output port. In this example, 
the first available input port that has a request for output 
port 0 is input port 1. Input port 0 is the first available 
input port that has a request for output port 1. Output 
port 2 selects input port 3 and output port 3 selects 
input port 1. After the output ports have selected an 
input port, grants are issued to those of the input ports 
that have been selected. In this example, therefore, 
grants are issued from output port 0 to input port 1 , from 
output port 1 to input port 0, from output port 2 to input 
port 3, and from output port 3 to input port 1. 
[0064] Turning now to Figure 7B, continuing with 
the present example, a grant is depicted as a dotted line 
from an output port to an input port and accepts are 
depicted as solid lines from input ports to output ports. 
For purposes of arbitrating among multiple grants, each 
input port has a corresponding priority indicator, IRRC 
0-3, shown pointing to output ports 1, 3, 2, and 0, 



respectively. Therefore, during this scheduling cycle, 
output port 1 receives priority over any other output 
ports contending for input port 0, output port 3 receives 
priority over any other output ports contending for input 
5 port 1 , output port 2 receives priority over any other out- 
put ports contending for input port 2, and output port 0 
receives priority over any other output ports contending 
for input port 3. 

[0065] During the accept phase (step 630), each 
w input port that is available searches its corresponding 
grant vector 735-738, respectively, in a circular fashion 
beginning with the output port identified by the associ- 
ated IRRC 0-3 to select the first available output port 
that has a grant for that input port. In this example, the 
15 first available output port that has a grant for input port 0 
is output port 1 . Output port 3 is the first available output 
port that has a request for input port 1 . Input port 2 has 
received no grants and input port 3 selects output port 

2. After the input ports have selected an output port, 
20 accepts are issued to those of the output ports that have 

been selected. In this example, therefore, accepts are 
issued from input port 0 to output port 1 , from input port 
1 to output port 3, and from input port 3 to input port 2. 
Finally, those of the input ports and output ports that 

25 were matched (e.g., those of input ports issuing accepts 
and those of the output ports receiving accepts) are 
marked as unavailable. In this example, therefore, input 
ports 0, 1, and 3 and output ports 1-3 are marked as 
unavailable by setting input unavailability indicators 705, 

30 706, and 708 and output unavailability indicators 716- 
718, respectively, thereby removing these ports from 
consideration in subsequent iterations of the scheduling 
cycle. 

[0066] During the update phase (step 640), the 

35 IRRCs and the ORRCs are updated in accordance with 
the update mechanism described above. In this exam- 
ple, the value of ORRC 0 will remain unchanged since a 
request from the input port to which it points remains 
unserviced. The value of ORR^ will be updated to one 

40 since the request from input port 0 was serviced. The 
value of ORRC 2 will be updated to zero since the 
request from input port 3 was serviced. The value of 
ORRC 3 will be updated to two since the request from 
input port 1 was serviced. Meanwhile, on the input side, 

45 the value of IRRC 0 will be updated to two, the value of 
IRRC 1 will be updated to zero, and the values of both 
IRRC 2 and IRRC3 will be updated to three. 
[0067] Assuming the fabric 120 were configured 
according to this exemplary scheduling cycle iteration, 

50 the fabric configuration would cause a unicast cell to be 
transferred from input ports 0, 1 , and 3 to output ports 1 , 

3, and 2, respectively. 

[0068] Figure 8 is a high level block diagram of a 
hardware implementation of a unicast scheduler 
55 according to one embodiment of the present invention. 
For purposes of simplifying the discussion, this example 
addresses the case of a unicast scheduler 800 that sup- 
ports a single class of service. According to this embod- 
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iment, the unicast scheduler 800 consists of a set of 
active request vector registers 810, a set of output grant 
arbiters 850, a set of input accept arbiters 860, and a set 
of accept vector registers 870. 

[0069] The active request vector registers 810 are 
coupled to the output grant arbiters 850. The output 
grant arbiters 850 choose among contenting requests 
on behalf of the corresponding output port 109. At the 
beginning of each unicast scheduling cycle, transmit 
requests 235 from the input ports 107 are loaded into 
the active request vector registers 810. Each iteration of 
the scheduling cycle, N-bit request vectors 811 are pre- 
sented to each of the N corresponding output grant arbi- 
ters 850. 

[0070] Each of the output grant arbiters 850 are 
coupled to each of the input accept arbiters 860. The 
output grant arbiters 850 each select one of the compet- 
ing requests that is closest in priority to its ORRC and 
issue a grant signal to the input accept arbiter 860 cor- 
responding to the selected request. 
[0071] The input accept arbiters 860 are coupled to 
the set of accept vector registers 870 to identify the out- 
put port that has been matched with the corresponding 
input port. The input grant arbiters 860 each select one 
of the competing grants received from the output grant 
arbiters 850 that is closest in priority to its IRRC and 
issue an accept signal corresponding to the selected 
output port. The input accept arbiters 860 present 
accept signals in the form of an accept vector 871 to the 
set of accept vector registers 870. Each iteration, feed- 
back from the accept vector registers 870 may be used 
to mask off requests corresponding to ports that have 
already been matched during the scheduling cycle. 
Alternatively, once a port has been matched, the corre- 
sponding arbiter 850 or 860 may be disabled in all fur- 
ther iterations of the scheduling cycle in order to prevent 
the arbiter from making additional matches. At any rate, 
the accept signals are accumulated in the set of accept 
vector registers 870 during each iteration of the unicast 
scheduling cycle and, as discussed above, are used at 
the end of the unicast scheduling cycle to configure the 
fabric 120. 

Exemplary Round-Rob in Arbiters 

[0072] Figures 9A and 9B depict exemplary round- 
robin arbiters that may be used in accordance with one 
embodiment of the present invention. Referring first to 
Figure 9A, an output grant arbiter 950 that understands 
four classes of service is illustrated. In this example, the 
output grant arbiter 950 includes a grant priority filter 
905 and a programmable priority encoder 920, A plural- 
ity of request vectors 904 associated with one or more 
priority levels are received by the grant priority filter 905. 
The grant priority filter 905 selects the request vector 
associated with the highest priority class of service and 
allows those requests 91 5 to be presented to the pro- 
grammable priority encoder 920. As is well known, pro- 



grammable priority encoders select as an output one of 
its inputs as determined by a supplied priority indication. 
In this example, the programmable priority encoder 920 
grants one of the requests 915 based upon the highest 

5 priority 910, e.g., an ORRC. supplied by the grant prior- 
ity filter 905. The priority levels and the grants produced 
by N output grant arbiters 950 are presented to an input 
accept arbiter 990 such as that illustrated in Figure 9B. 
In this example, the input accept arbiter 990 includes an 

10 accept priority filter 945 and a programmable priority 
encoder 960. The accept priority filter 945 outputs the 
grants 955 associated with the highest priority class of 
service level. The programmable priority encoder 960 
accepts one of the grants 955 based upon the highest 

75 priority 951. e.g., an IRRC, supplied by the accept prior- 
ity filter 945. 

[0073] In one embodiment, the unicast scheduler 
220 may include N output grant arbiters 950 and N input 
accept arbiters 990. Importantly, however, the present 

20 invention is not limited to any particular round-robin 
arbiter, the multicast scheduler 215 and unicast sched- 
uler 220 may employ various other types of round-robin 
arbiters. For example, one of the fast programmable pri- 
ority encoders described in R Gupta and N. McKeown, 

25 "Design and Implementation of a Fast Crossbar Sched- 
uler," Hot Interconnects VI, Stanford University, August 
1998, which is hereby incorporated by reference, may 
be used. 

30 Combined Multicast and Unicast Scheduling 

[0074] According to one embodiment of the present 
invention, a novel scheduling approach permits unicast 
scheduling processing and multicast scheduling 

35 processing to operate in parallel and independently 
resulting in a combined schedule comprising both uni- 
cast and multicast cells. Parallelism may be achieved, 
for example, by pipeline staging of unicast and multicast 
scheduling. Pipelining unicast and multicast scheduling 

40 is advantageous, for example, if the duration of the cell 
scheduling cycle is insufficient to accommodate both 
unicast and multicast scheduling in serial. Prior sched- 
uling approaches produce uniform schedules that are 
limited to either ail unicast cells or all multicast cells. In 

45 contrast, the novel combined scheduling approach per- 
mits a combined schedule to be produced comprising 
both unicast and multicast cells. In this manner, both 
multicast and unicast cells may be transferred across 
the fabric 120 during the same time slot. Additionally, 

so the separation of unicast and multicast scheduling 
results in increased flexibility and programmability of the 
rate at which unicast and/or multicast traffic is serviced. 
[0075] Referring now to Figure 10A, a general flow 
diagram is described illustrating combined scheduling 

55 processing for two different types of traffic according to 
one embodiment of the present invention. This example 
assumes cell scheduling processing is performed once 
each time slot, cell scheduling for one of the types of 
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traffic, i.e., the first traffic type, is performed less than 
every time slot, cell scheduling for the other type of traf- 
fic, i.e., the second traffic type is performed every time 
slot, cells of the first traffic type are scheduled at least 
one time slot in advance of their transfer across the fab- 
ric 120, cells of the second traffic type are scheduled 
and transferred in the same time slot, and when both 
cells of the first and second traffic type. 
[0076] According to this example, at step 1005, a 
determination is made whether or not to perform sched- 
uling for the first type of traffic based upon a predeter- 
mined scheduling frequency 1001. The scheduling 
frequency 1001 may be a hardcoded value or a pro- 
grammable parameter as will be discussed further 
below. At any rate, if cell scheduling is to be performed 
for the first type of traffic during the current time slot, 
then processing continues with steps 1015 and 1020. 
Steps 1015 and 1020 are preferably performed by sep- 
arate and independent celt scheduling units, as dis- 
cussed above, thereby providing the ability to perform 
the cell scheduling for the two types of traffic in parallel. 
At step 1020, a cell scheduling cycle for the first type of 
traffic is performed and the results are stored for a sub- 
sequent time slot. Concurrently, in step 1015 a cell 
scheduling cycle for the second type of traffic is per- 
formed for the current time slot. During time slots in 
which both the cells of the first and second type of traffic 
are to be transferred, the prior scheduling results for the 
first type of traffic 1002 are fed into the scheduling 
processing for the second type of traffic (step 1015) and 
the scheduler schedules cells of the second type of traf- 
fic whose ports are not being used by the previously 
scheduled cells of the first type of traffic. When both 
scheduling cycles have been finalized, the combined 
scheduling processing is complete. 
[0077] Returning to step 1005, if cell scheduling is 
not to be performed for the first type of traffic during the 
current time slot, then processing continues with step 
1010. In step 1010, a cell scheduling cycle for the sec- 
ond type of traffic is performed for the current time slot. 
As above, during time slots in which both the cells of the 
first and second type of traffic are to be transferred, the 
prior scheduling results for the first type of traffic 1002 
are fed into the scheduling processing for the second 
type of traffic (step 1010) and the scheduler schedules 
cells of the second type of traffic whose ports are not 
being used by the previously scheduled cells of the first 
type of traffic. When the scheduling cycle has been 
finalized, the combined scheduling processing is com- 
plete. 

[0078] In alternative embodiments, if the duration of 
the time slot is greater than or equal to the time required 
to perform both scheduling cycles without overlap, then 
the cell scheduling cycles may be performed serially. 
Additionally, in alternative embodiments, scheduling fre- 
quencies may be supplied for both the first type and the 
second type of traffic. 

[0079] Figure 1 0B is a flow diagram illustrating an 



embodiment of Figure 10A in which unicast and multi- 
cast scheduling may be combined. In the embodiment 
depicted, multicast and unicast cell scheduling operate 
separately and independently, however during selected 

5 time slots when both multicast traffic and unicast traffic 
are scheduled for transfer across the fabric 120, unicast 
cells are scheduled based upon the results of an earlier 
multicast scheduling cycle. For example, unicast cells 
may be scheduled at a lower priority than the multicast 

10 cells by limiting the ports available to the unicast sched- 
uler 220 to those ports that are left unmatched by the 
earlier multicast scheduling cycle. 
[0080] At step 1025, a determination is made 
whether or not to perform multicast scheduling based 

15 upon a predetermined multicast scheduling frequency 
1003. If multicast scheduling is to be performed during 
the current time slot, then processing continues with 
steps 1035 and 1040. Steps 1035 and 1040 are prefer- 
ably performed by separate and independent schedul- 

20 ers, such as unicast scheduler 220 and multicast 
scheduler 215 discussed above, thereby providing the 
ability to perform the multicast and unicast scheduling in 
parallel. At step 1040. a multicast scheduling cycle is 
performed and the results are stored for a subsequent 

25 time slot. Concurrently, in step 1035 a unicast schedul- 
ing cycle is performed for the current time slot. If both 
unicast and multicast cells are to be transferred during 
the current time slot, then the prior multicast scheduling 
results 1004 are input into the unicast scheduling 

30 processing (step 1035) and the unicast scheduler 220 
schedules unicast cells whose ports are not being used 
by the previously scheduled multicast cells. When both 
scheduling cycles have been finalized, the combined 
scheduling processing is complete. 

35 [0081] Returning to step 1025, if multicast schedul- 
ing is not to be performed during the current time slot, 
then processing continues with step 1030. In step 1030, 
a unicast scheduling cycle is performed for the current 
time slot. Again, if both unicast and multicast cells are to 

40 be transferred during the current time slot, then the prior 
multicast scheduling results 1004 are input into the uni- 
cast scheduling processing (step 1030) and the unicast 
scheduler 220 schedules unicast cells whose ports are 
not being used by the previously scheduled multicast 

45 cells. When the scheduling cycle has been finalized, the 
combined scheduling processing is complete. 
[0082] Figure 100 is a flow diagram illustrating 
another embodiment of Figure 1 0A in which unicast and 
multicast scheduling may be combined. In this embodi- 

50 ment, multicast and unicast cell scheduling operate 
separately and independently as above, however when 
both multicast traffic and unicast traffic are scheduled 
for transfer across the fabric 120, multicast cells are 
scheduled based upon the results of an earlier unicast 

55 scheduling cycle. For example, multicast cells may be 
scheduled at a lower priority than the unicast cells by 
limiting the ports available to the multicast scheduler 
215 to those ports left unmatched by the earlier multi- 
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cast schedule. 

[0083] At step 1045, a determination is made 
whether or not to perform unicast scheduling based 
upon a predetermined unicast scheduling frequency 
1006. If unicast scheduling is to be performed during 5 
the current time slot, then processing continues with 
steps 1055 and 1060. Steps 1055 and 1060 are prefer- 
ably performed by separate and independent schedul- 
ers, such as multicast scheduler 215 and unicast 
scheduler 220 discussed above, thereby providing the w 
ability to perform the multicast and unicast scheduling in 
parallel. At step 1060, a unicast scheduling cycle is per- 
formed and the results are stored for a subsequent time 
slot. Concurrently, in step 1055 a multicast scheduling 
cycle is performed for the current time slot. If both uni- 15 
cast and multicast ceils are to be transferred during the 
current time slot, then the prior unicast scheduling 
results 1007 are input into the multicast scheduling 
processing (step 1055) and the multicast scheduler 215 
schedules multicast cells whose ports are not being 20 
used by the previously scheduled unicast cells. When 
both scheduling cycles have been finalized, the com- 
bined scheduling processing is complete. 
[0084] Returning to step 1 045, if unicast scheduling 
is not to be performed during the current time slot, then 25 
processing continues with step 1050. In step 1050, a 
multicast scheduling cycle is performed for the current 
time slot. Again, if both unicast and multicast celts are to 
be transferred during the current time slot, then the prior 
unicast scheduling results 1007 are input into the multi- 30 
cast scheduling processing (step 1050) and the multi- 
cast scheduler 215 schedules multicast cells whose 
ports are not being used by the previously scheduled 
unicast cells. When the scheduling cycle has been final- 
ized, the combined scheduling processing is complete. 35 

Pipelined Staging of Multicast and Unicast Scheduling 

[0085] Figure 11A conceptually illustrates a pipe- 
lined approach for scheduling multicast and unicast traf- 40 
fic according to one embodiment of the present 
invention. Multicast scheduling 1 100 is shown along the 
top row. Unicast scheduling 1110 is shown along the 
middle row. The bottom row indicates the resulting com- 
bined schedule 1120. The hollow arrows point in the 45 
direction of the time slot during which the resulting 
schedule is used. For example, multicast schedule M 0 is 
generated during time slot t 0 , but is used during time 
slot t v 

[0086] A multicast scheduling frequency register so 
1003 identifies those of the time slots, e.g., t 0 - 1 7 . during 
which multicast scheduling 1100 is to be performed. 
Many possible implementations of the multicast sched- 
uling frequency register 1003 have been contemplated. 
According to one embodiment, a circular register is 55 
implemented, where the bits of the register are set to T 
or '0' in accordance with whether the current time slot is 
a multicast time slot. Each time slot, the bits of the reg- 



ister are rotated and the LSB or the MSB can be evalu- 
ated. Alternatively, the multicast scheduling frequency 
register 1003 may be implemented as an up or a down 
circular counter. Each time slot, the counter is incre- 
mented or decremented and the value in the counter is 
compared to a predetermined value that indicates when 
multicast scheduling is to be performed. According to 
one embodiment, the multicast scheduling frequency 
register 1003 contains a hardcoded value. In alternative 
embodiments, however, the multicast scheduling fre- 
quency register 1003 is a programmable parameter 
thereby allowing the provision of variable rate multicast 
servicing and putting a cap on the total bandwidth avail- 
able to multicast traffic. Responsive to historical network 
usage or scheduled network usage, the multicast 
scheduling frequency register 1003 may be adjusted 
upward or downward automatically by a traffic monitor- 
ing process, for example. Alternatively, bandwidth may 
be allocated between unicast and multicast traffic by the 
network administrator by tuning the multicast schedul- 
ing frequency. 

[0087] In the example illustrated by Figure 1 1 A, if a 
bit position in the multicast scheduling frequency regis- 
ter 1003 contains a *1,' then multicast scheduling 1100 
is performed during the corresponding time slot; other- 
wise no multicast scheduling is performed during the 
time slot. According to the embodiment depicted, uni- 
cast scheduling 1110 is performed every time slot. 
Assuming the duration of a time slot is insufficient to 
accommodate both unicast and multicast scheduling in 
serial, the novel combined scheduling approach 
described herein permits a combined schedule 1120 to 
be generated by employing a pipelined scheduling 
approach. 

[0088] Briefly, in this example, multicast scheduling 
time slots occur as a subset of unicast scheduling time 
slots. Unicast scheduling 1110 occurs every time slot 
and multicast scheduling 1100 occurs every other time 
slot. During the first time slot, to, both multicast schedul- 
ing and unicast scheduling are performed in parallel. 
The multicast scheduling cycle produces a first multi- 
cast schedule, M 0 , for the next time slot, t-j, and the uni- 
cast scheduling cycle produces a first unicast schedule, 
U 0 , for the current time slot, t 0 . Since no multicast cells 
are scheduled for t 0 , the resulting combined schedule is 

[0089] Referring now to the next time slot, t 1( no 
multicast scheduling is performed, but the results of the 
previous multicast scheduling cycle, M 0 , are fed into the 
unicast scheduling cycle. As a result, only those ports 
that are left unclaimed by M 0 are available for use by the 
unicast scheduling. The resulting unicast schedule, U-,, 
is therefore limited to filling in ports that were not 
matched during the earlier multicast scheduling cycle. 
In this manner, when both unicast and multicast cells 
are to be transferred during the same time slot, unicast 
cells are effectively treated as a lower priority than the 
previously scheduled multicast cells. Cell scheduling 
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proceeds in a similar manner for the remaining time 
slots. 

[0090] In alternative embodiments, multicast 
scheduling may be triggered differently than as 
described above. Bit positions in the multicast schedul- 
ing frequency register 1003 containing a '0' may cause 
multicast scheduling to be performed in the correspond- 
ing time slot while a '1 ' may inhibit multicast scheduling. 
Alternatively, as mentioned above, multicast scheduling 
may be triggered by a circular counter. For example, 
when the counter is incremented or decremented to a 
predetermined value this event may cause a multicast 
scheduling cycle to be performed. Additionally, in alter- 
native embodiments, multicast scheduling may be per- 
formed more than one time slot in advance of its use. 
Further, while ah eight bit register is depicted for pur- 
poses of illustration, registers of more or fewer bits may 
be used depending upon the needs of a particular 
implementation. Finally, although the examples only 
show control of multicast traffic, it is contemplated that 
the scheduling of unicast traffic may be similarly trig- 
gered (in addition to or instead of multicast traffic trig- 
gering) by employing a unicast scheduling frequency 
register (not shown). 

[0091] Turning now to Figure 11 B, a pipelined 
approach for scheduling multicast and unicast traffic 
according to another embodiment of the present inven- 
tion is conceptually illustrated. As in the previous exam- 
ple, unicast scheduling 1110 is performed during every 
time slot and if a bit position in the multicast scheduling 
frequency register 1003 contains a '1,' then multicast 
scheduling 1100 is also performed during the corre- 
sponding time slot; otherwise no multicast scheduling is 
performed during the time slot. Also, as above, multicast 
scheduling time slots occur as a subset of unicast 
scheduling time slots. This example illustrates that mul- 
ticast scheduling 1110 may be performed more than 
one time slot in advance of the use of the resulting 
schedule. Additionally, multicast scheduling 1110 need 
not be symmetric or uniformly distributed. For example, 
multicast scheduling 1110 is not limited to being per- 
formed every other time slot as shown in Figure 11 A. 
Rather, if desired, multicast scheduling 1110 may be 
performed during two or more consecutive time slots, so 
long as during at least one time slot unicast traffic is 
given priority to ensure unicast traffic has adequate 
access to the fabric 120. 

[0092] According to this example, during the first 
time slot, t 0 , both multicast scheduling and unicast 
scheduling are performed in parallel. The multicast 
scheduling cycle produces a first multicast schedule, 
M 0 , for use in time slot, t 2 , and the unicast scheduling 
cycle produces a first unicast schedule, U 0 , for the cur- 
rent time slot, t 0 . Since no multicast cells are scheduled 
for to, the resulting combined schedule is U 0 . Multicast 
scheduling is performed for time slott3 during time slot, 
t1. Again, since no multicast cells are scheduled for t1, 
the resulting combined schedule is U 1t The unicast 



scheduling cycle performed during time slot t2 is 
dependent upon the results of the previous multicast 
scheduling cycle, M 0 thereby giving the previously 
scheduled multicast cells priority over the unicast cells 
5 for the current time slot. Cell scheduling proceeds in a 
similar manner for the remaining time slots. 

Back Pressure Handling 

w [0093] Because a head-of-line multicast cell can 
block the rest of the cells in the multicast queue, even 
though they are headed for different output ports, spe- 
cial handling of output port backpressure signals is 
needed to avoid the head-of-line blocking problem for 

15 multicast traffic to protect multicast performance. As 
described above, prior architectures typically backpres- 
sure the input ports directly from each of the output 
ports. Thus requiring knowledge / logic for backpres- 
sure handling at each of the input ports. In contrast, 

20 according to one embodiment of the present invention, 
the output ports 109, backpressure the fabric arbiter 
110. Consequently, knowledge / logic for backpressure 
handling is centralized within the fabric arbiter 110 
thereby reducing the complexity of the input ports 107. 

25 [0094] Briefly, according to one embodiment, each 
time slot, the output ports 109 communicate an N-bit 
backpressure signal to the fabric arbiter 110 indicating 
whether or not one or more of the corresponding output 
queues has filled up. Then, the fabric arbiter 110 makes 

30 multicast scheduling decisions based upon the back- 
pressure signal and the status of the multicast queues. 
According to one embodiment, the fabric arbiter 110 is 
configured to operate in one of two modes of operation 
with respect to a backpressuring output port. In the first 

35 mode of operation, the fabric arbiter obeys the back- 
pressure signal and does not include the backpressur- 
ing output port in the fabric configuration. In the second 
mode of operation, the fabric arbiter solves the head-of 
line blocking problem by ignoring the backpressure sig- 

40 nal and causing the head-of-line multicast cells destined 
for the backpressuring output port to be transferred to 
the backpressuring output port regardless of the back- 
pressure signal. When received by the backpressuring 
output port, the head-of-line multicast cell may be 

45 accepted if the output port has room or dropped. In this 
manner, multicast performance is protected by allowing 
the remainder of the multicast cells the opportunity to be 
transferred. According to one embodiment, in order to 
reduce oscillation of the backpressure signals from time 

so slot to time slot, once a backpressure signal is asserted 
it is not de-asserted until a certain amount of time has 
passed or until a the output queue size has fallen below 
a predetermined threshold. For example, de-assertion 
of the backpressure signal may be delayed until the 

55 backpressuring output queue is half-empty. 

[0095] Figure 12 is a flow diagram illustrating back- 
pressure processing according to one embodiment of 
the present invention. At step 1210, the fabric arbiter 
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110 receives back pressure signals from the output 
ports 109. At step 1220, a determination is made 
whether or not to obey the backpressure signals based 
upon the size (length) of the multicast queues. If a mul- 
ticast queue reaches a certain high watermark thresh- 5 
old, processing continues with step 1230. Otherwise, 
processing proceeds to step 1240. 
[0096] At step 1230, requests associated with back- 
pressuring output ports are not masked and are there- 
fore considered eligible for multicast scheduling. In this 10 
manner, the head-of-line cell is sent to the destined out- 
put port(s) 109 regardless of the backpressure signal 
thereby removing the blockage and allowing the remain- 
ing multicast cells an opportunity to be scheduled for 
transfer across the fabric 120. At step 1240, no multi- is 
cast build up has occurred, therefore, requests associ- 
ated with backpressuring output ports are masked and 
are not considered by the multicast scheduler 215. After 
either of steps 1230 or 1240, processing continues with 
step 1250. At step 1250, multicast scheduling is per- 20 
formed based upon the requests that remain after step 
1230 or 1240. Advantageously, one overloaded output 
port is prevented from adversely affecting other unre- 
lated output ports. 

[0097] Referring now to Figure 13, a block diagram 25 
of an exemplary hardware implementation of a portion 
of backpressure logic 1300 will now briefly be 
described, according to one embodiment of the present 
invention. An original request vector 130 is masked or 
not based upon a backpressure override signal 1330 30 
and a resulting request vector 1340 is output from the 
backpressure logic 1300. In this example, the backpres- 
sure logic 1300 comprises a backpressure mask 1305, 
N AND gates 1320, and N multiplexors 1325. In this 
example, a bit position of the backpressure mask 1305 35 
contains a '0' if the corresponding output port / queue is 
backpressuring or a '1* is the output port /queue is not 
backpressuring. In this manner, the requests associated 
with backpressured output ports / queues can be 
masked off. However, the backpressure override signals 40 
1330 allow one or more of the original request vector 
positions to be passed through unchanged in the case 
of multicast queue buildup at an input port, for example. 
[0098] In the foregoing specification, the invention 
has been described with reference to specific embodi- 45 
ments thereof. It will, however, be evident that various 
modifications and changes may be made thereto with- 
out departing from the broader spirit and scope of the 
invention. The specification and drawings are, accord- 
ingly, to be regarded in an illustrative rather than a 50 
restrictive sense. 

Claims 

1. A method of performing multicast and unicast 55 
scheduling in a network device, the method com- 
prising the steps of: 



performing unicast cell scheduling each sched- 
uling timeslot of a set of possible scheduling 
timeslots; and 

performing multicast cell scheduling in parallel 
with and independent of the unicast cell sched- 
uling during a subset of the possible scheduling 
timeslots. 

2. The method of claim 1 , wherein the network device 
includes a switched backplane controlled by two 
independent schedulers, a multicast scheduler and 
a unicast scheduler, and wherein: 

the step of performing multicast cell scheduling 
in parallel with and independent of the unicast 
cell scheduling during a subset of the possible 
scheduling timeslots includes the multicast 
scheduler scheduling multicast cells for trans- 
mission among a plurality of interfaces of the 
switched backplane by performing a multicast 
cell scheduling cycle for a plurality of classes of 
service that are supported by the network 
device; and 

the step of performing unicast cell scheduling 
each scheduling timeslot of a set of possible 
scheduling timeslots includes the unicast 
scheduler scheduling unicast cells for trans- 
mission among a plurality of interfaces of the 
switched backplane at a lower priority than the 
multicast cells scheduled by the multicast 
scheduler by performing a unicast cell schedul- 
ing cycle for the plurality of classes of service 
using only those interfaces that remain 
unmatched after completion of the multicast 
cell scheduling cycle. 

3. The method of claim 2, wherein: 

the step of performing multicast cell scheduling 
in parallel with and independent of the unicast 
cell scheduling during a subset of the possible 
scheduling timeslots includes the multicast 
scheduler outputting state information to the 
unicast scheduler; and 

the step of performing unicast cell scheduling 
each scheduling timeslot of a set of possible 
scheduling timeslots includes the unicast 
scheduler identifying those of the interfaces 
that remain unmatched based upon the state 
information. 

4. A method of combining multicast and unicast 
scheduling in a network device comprising the 
steps of: 

scheduling multicast cells for transmission 
among a plurality of interfaces of a crossbar by 
performing a multicast cell scheduling cycle for 
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a plurality of classes of service that are sup- 
ported by the network device; and 
scheduling unicast cells for transmission 
among the plurality of interfaces at a lower pri- 
ority than the multicast cells scheduled by the 5 
multicast cell scheduling cycle by performing a 
unicast cell scheduling cycle for the plurality of 
classes of service using only those interfaces 
that remain unmatched after completion of the 
multicast celt scheduling cycle. w 

The method of claim 4, wherein the network device 
includes two independent schedulers, a multicast 
scheduler and a unicast scheduler, and wherein: 

15 

the step of scheduling multicast cells includes 
the multicast scheduler outputting state infor- 
mation to the unicast scheduler; and 
the step of scheduling unicast cells includes 
the unicast scheduler identifying those of the 20 
interfaces that remain unmatched based upon 
the state information. 

A method of combining multicast and unicast 
scheduling comprising the steps of: 25 

scheduling multicast cells for transmission 
among a plurality of interfaces of a crossbar by 
performing a multicast cell scheduling cycle 
including a executing scheduling iterations for a 30 
plurality of classes of service that are sup- 
ported by the network device and producing 
availability information indicative of those of the 
plurality of interfaces that remain available for 
scheduling; and 35 
scheduling unicast cells for transmission 
among the plurality of interfaces at a lower pri- 
ority than the multicast cells by performing a 
unicast cell scheduling cycle after the multicast 
cell scheduling cycle and using only those 40 
interfaces identified by the availability informa- 
tion. 

A method of performing multicast and unicast 
scheduling in a network device, the method com- 45 
prising the steps of: 

during a first predetermined set of scheduling 
timeslots of a set of possible scheduling times- 
lots, performing both multicast cell scheduling so 
and unicast cell scheduling, the multicast cell 
scheduling, and the unicast cell scheduling 
operating in parallel and independent of each 
other; and 

during a second predetermined set of schedul- 55 
ing timeslots of the set of possible scheduling 
timeslots, performing unicast cell scheduling 
based upon results of the multicast cell sched- 



uling completed during a previous scheduling 
timeslot. 

8. The method of claim 7, wherein the first predeter- 
mined set of scheduling timeslots comprises every 
other timeslot of the set of possible scheduling 
timeslots. 

9. The method of claim 7 or 8, wherein the step of per- 
forming unicast cell scheduling based upon results 
of the multicast cell scheduling completed during a 
previous scheduling timeslot comprises performing 
unicast cell scheduling during timeslot t+1 based 
upon results of the multicast cell scheduling com- 
pleted during timeslot t. 

10. A method of combining multicast and unicast 
scheduling comprising the steps of: 

performing a multicast cell scheduling cycle 
during timeslot t for multicast cells that are to 
be transmitted across a fabric of a network 
device during timeslot t+n, the fabric coupling 
each of a plurality of input ports to each of a 
plurality of output ports, the multicast cell 
scheduling cycle including a scheduling itera- 
tion for each class of service supported by the 
network device and producing availability infor- 
mation indicative of those of the plurality of 
input ports and output ports that remain availa- 
ble for scheduling during timeslot t+n; and 
performing a unicast cell scheduling cycle dur- 
ing timeslot t+n based upon the availability 
information, the unicast cell scheduling cycle 
scheduling unicast cells for transmission 
across the fabric during timeslot t+n. 

11. The method of claim 10, wherein n equals 0 or n 
equals 1. 

12. The method of claim 10 or 11, further comprising 
the step of performing a unicast cell scheduling 
cycle during timeslot t for unicast cells that are to be 
transmitted across the fabric during timeslot t in 
parallel with the step of performing a multicast cell 
scheduling cycle during timeslot t. 

13. The method of claim 17, further comprising the step 
of performing a unicast cell scheduling cycle during 
every timeslot. 

14. The method of claim 12 or 13, further comprising 
the step of performing a multicast cell scheduling 
cycle less frequently than every timeslot. 

15. A network device comprising: 

a plurality of input ports and output ports resid- 
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ing on a plurality of line cards; a fabric coupled 
to the plurality of line cards, the fabric including 
a switched backplane allowing the simultane- 
ous transfer of data among the plurality of input 
ports and output ports; and 5 
a fabric configuration manager coupled to the 
fabric and the plurality of line cards, the fabric 
configuration manager including two independ- 
ent schedulers, a multicast scheduler and a 
unicast scheduler, the multicast scheduler and 10 
the unicast scheduler operating independently 
and in parallel to match pairs of the plurality of 
ports for the transfer of multicast cells and uni- 
cast celts across the fabric, respectively, during 
a first predetermined set of scheduling times- 15 
lots, and during a second predetermined set of 
scheduling timeslots, the unicast scheduler 
performing unicast scheduling among those 
ports of the plurality of ports that remain 
unmatched by a prior multicast scheduling 20 
cycle. 

16. A computer program element comprising computer 
program code means to make a controller execute 
procedure to perform the method steps of any of 25 
claims 1 to 14. 

17. The computer program element of claim 16, 
embodied on a computer readable medium. 
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